Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invariant Monitor contract #1017

Merged
merged 43 commits into from
Jan 15, 2024
Merged

Invariant Monitor contract #1017

merged 43 commits into from
Jan 15, 2024

Conversation

julianmrodri
Copy link
Contributor

@julianmrodri julianmrodri commented Nov 29, 2023

  • Monitor specific RTokens
  • Meant to be used by a monitoring system
  • Set as UUPS Proxy
  • Backing Redeemable checks support: AAVE V2, AAVE V3, COMPOUND V2, COMPOUND V3., Stargate, FLUX, and Morpho AAVE V2.
  • (need to pass the address of the ERC20 being used in the RToken as collateral - wrapped/static token)
    *Includes deployment address and docs

Deployment task available:

  • For the initial deployment:
    npx hardhat deploy-facade-monitor --upgrade false --owner OWNER_ADDR --network mainnet

  • For deploying just the new implementation to be used in upgrade:
    npx hardhat deploy-facade-monitor --upgrade true --network mainnet

@pmckelvy1
Copy link
Collaborator

im thinking its probably worth it to split this contract up into multiple. it would be a lot easier to maintain each individual monitoring function if they need to be tweaked or upgraded (less gas costs to do individual deployments).
another thing to consider is using a proxy for each monitoring function contract, allowing them to updated individually. this would have the benefit of not needing to change anything in hypernative if we need to do an update.
open to thoughts here as i'm not sure yet what the best path is.

@pmckelvy1
Copy link
Collaborator

im thinking its probably worth it...

maybe for simplicity's sake, we just make this a proxy and use a single contract for now. if we get to a point of wanting to make change or add functionality, we can reassess if a single contract is the best route, but for now, a single upgradeable proxy is probably easiest.

the only concern there is who is the admin? i think there is a msig we can use to approve upgrades.

Copy link

openzeppelin-code bot commented Dec 8, 2023

Invariant Monitor contract

Generated at commit: e1d216497f58f9e53a34aac208150a280f4de60d

🚨 Report Summary

Severity Level Results
Contracts Critical
High
Medium
Low
Note
Total
2
1
0
18
36
57
Dependencies Critical
High
Medium
Low
Note
Total
0
0
0
0
0
0

For more details view the full report in OpenZeppelin Code Inspector

@julianmrodri julianmrodri reopened this Dec 13, 2023
@julianmrodri julianmrodri marked this pull request as ready for review December 13, 2023 12:50
@julianmrodri
Copy link
Contributor Author

@pmckelvy1 This is ready, included the morpho change, deployed and upgraded the monitors in Base and Mainnet

Copy link
Collaborator

@pmckelvy1 pmckelvy1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@pmckelvy1 pmckelvy1 merged commit d7315fb into 3.1.0 Jan 15, 2024
10 checks passed
@pmckelvy1 pmckelvy1 deleted the feat-invariantmonitor branch January 15, 2024 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants